[% setvar title The Perl 6 Summary for the week ending 2004-03-28 %]
<div id="archive-notice">
    <h3>This file is part of the Perl 6 Archive</h3>
    <p>To see what is currently happening visit <a href="http://www.perl6.org/">http://www.perl6.org/</a></p>
</div>
<div class='pod'>
<a name='The Perl 6 Summary for the week ending 2004-03-28'></a><h1>The Perl 6 Summary for the week ending 2004-03-28</h1>
<p>... and we're back! Another interesting week in Perl 6. Your Summarizer
even wrote some [parrot] code and it's been simply ages since he did
that. In accordance with ancient custom, we'll start the summary with
perl6-internals.</p>
<a name='Building with miniparrot'></a><h2>Building with miniparrot</h2>
<p>Back in the early days Dan proposed, and it was generally agreed that
the Parrot build process wouldn't be Perl dependent, but instead there
would be a few OS specific 'bootstrap' scripts, enough to get
<b><i>miniparrot</i></b> up and running. Miniparrot would have just enough smarts
to be able to complete the configuration and build the final full
parrot.</p>
<p>After last week's discussion about reinventing metaconfig, I wondered
if the miniparrot plan was still in place. It seems I'd missed the
discussion of <code>stat</code> that ended up talking about how miniparrot would
be able to do its job. I find myself wondering what else is needed to
get miniparrot to the point where it can start doing configuration work.</p>
<p><a href='http://groups.google.com/groups?selm=a06010202bc74cd596e93@' target='_blank'>groups.google.com</a>[10.0.1.2]</p>
<a name='Continuations continued (and fun with stacks)'></a><h2>Continuations continued (and fun with stacks)</h2>
<p>Warning: The following discussion of the Continuation discussions is
irrevocably biased; I find it very hard to be objective about discussions
I participate in, and I was rather loud mouthed in this one.</p>
<p>The previous discussions of the uses and semantics of continuations
carried over into this week. Piers Cawley argued that the current stack
architecture seemed to be optimized for the wrong thing, with the
special case RetContinuations being symptoms. He argued that current
architecture (where a single stack frame can accommodate multiple
pushes, with copy on write semantics being used to handle full
continuations) should be replaced with a 'naïve' architecture using
linked lists of immutable, simple stack frames, one frame per
push. Switching to this approach, he argued, would do away with a great
deal of code complexity, and issues of high object creation overhead
could be offset by using free lists and preallocation to reuse stack
frames. Oh yes, and there'd be no difference between a RetContinuation
and a full Continuation with this scheme.</p>
<p>Leo Tötsch wasn't convinced. Dan was though, and made the decision to
switch to single item per frame, immutable, non COW stacks. Leo
implemented it. His first cut was rather slow; later refinements added
freelists and other handy stuff to start pulling the performance back
up. I'm sure there's more refinement to come though.</p>
<p><a href='http://groups.google.com/groups?selm=200403171746.i2HHkon26793@thu8.leo.home' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?selm=m2llluszax.fsf@obelisk.bofh.org.uk' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?selm=a0601024ebc84a9496605@' target='_blank'>groups.google.com</a>[10.0.1.2]</p>
<p><a href='http://groups.google.com/groups?selm=406020C3.9040904@toetsch.at' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?selm=rt-3.0.8-27904-82629.6.64105174468546@perl.org' target='_blank'>groups.google.com</a></p>
<a name='Variadic functions'></a><h2>Variadic functions</h2>
<p>Ilya Martynov had some questions about how to handle variadic
functions. Leo clarified some things and pointed Ilya at the <code>foldup</code>
op. Jens Rieks suggested aliasing the registers <code>I[1-4]</code> to
<code>argc[ISPN]</code>, which Leo liked. I'm not sure he's implemented it yet
though.</p>
<p><a href='http://groups.google.com/groups?selm=87zna9z04w.fsf@moto.localhost' target='_blank'>groups.google.com</a></p>
<a name='GCC compiling to Parrot'></a><h2>GCC compiling to Parrot</h2>
<p>In previous weeks Gerard Butler had posted wondering about getting GCC
to target Parrot. The initial response was rather negative, pointing
out that GCC and Parrot saw memory <i>very</i> differently, to the extent
that there would probably be a need have special PMCs for GCC managed
memory, which would make communication between GCC implemented
languages and Parrot implemented ones rather tricky.</p>
<p>Undeterred, Gerald mapped out a way forward and asked for opinions. Dan
thought the scheme looked reasonable, but fenced that with the caveat
that he knows nothing about GCC's internals.</p>
<p><a href='http://groups.google.com/groups?selm=FE6307104985D611A92A0002A5F3AB00B9D867@exch1.Sterling.COM' target='_blank'>groups.google.com</a></p>
<a name='Safe execution core and ops classification'></a><h2>Safe execution core and ops classification</h2>
<p>Leo checked in some patches from Jens Rieks to allow classification of
ops. He thought that this meant we were a good way along the road to
providing a 'Safe' run-core option, though there was still a lot to
do. He outlined a road map and asked for comments (and
implementations). Comments were forthcoming, and Dan eventually bundled
his comments up into a single post with some design in it. For some
reason this induced some industrial hand waving about Proof Carrying
Code from Steve Fink (he accused himself of hand waving, not me).</p>
<p>Jarkko Hietaniemi (Emacs' dynamic completion suggested 'Jarkko Himself'
for that one. Well, it made <i>me</i> smile) offered the pathological</p>
<pre>    eval 'while(<a href='mailto:push@a'>push@a</a>,0){}'</pre>
<p>as an example of the kind of bad things that can happen if you allow
<code>eval EXPR</code> in your 'safe' code, even with strict rules on what it's
allowed to compile (Dan pointed out that quotas would help in this
particular case...)</p>
<p>If there's one lesson to take from the discussion it's this: Code
Safety is Hard. Whether it's AI Hard or not is left as an exercise for
the interested reader.</p>
<p><a href='http://groups.google.com/groups?selm=405FE432.1010607@toetsch.at' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?selm=59D9DAFBB46CD51184170002A513650E0A23EF01@rosnt76.ets.org' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?selm=a06010200bc8638b16f58@' target='_blank'>groups.google.com</a>[172.24.18.98] -- Dan's big(gish) post</p>
<a name='UNO (Universal Network Objects) interface for Parrot?'></a><h2>UNO (Universal Network Objects) interface for Parrot?</h2>
<p>Tim Bunce pointed everyone at OpenOffice's Universal Network Objects
and wondered if anyone had had a look to see what is needed to plug
Parrot into them. And was promptly Warnocked.</p>
<p><a href='http://groups.google.com/groups?selm=20040324004749.GD26716@dansat.data-plan.com' target='_blank'>groups.google.com</a></p>
<p><a href='http://udk.openoffice.org/' target='_blank'>udk.openoffice.org</a> -- More on UNO</p>
<a name='Load paths'></a><h2>Load paths</h2>
<p>In Perl, it's possible to write <code>require Some::Module</code>, and Perl will
go off and hunt for the appropriate file in the various directories in
its <code>@INC</code>. You can do something similar in most languages.</p>
<p>Right now, you can't do it in Parrot though; Parrot's <code>load_bytecode</code>
and other such ops take filesystem paths so, if things aren't set up
exactly as the programmer expects, Bad Things can happen.</p>
<p>As Dan (and others on IRC and elsewhere I'm sure) points out, this is
sub optimal. He posted an overview of the issue and a few possible ways
forward and asked for comments. There were several. Mostly along the
lines of 'core support for full over the net URIs for bytecode loading
would be unutterably Bad'.</p>
<p><a href='http://groups.google.com/groups?selm=a06010208bc87749f2ab5@' target='_blank'>groups.google.com</a>[10.0.1.2]</p>
<a name='Tcl, looking for a few good people'></a><h2>Tcl, looking for a few good people</h2>
<p>Will Coleda's Tcl implementation has apparently reached the point where
he'd appreciate assistance. He said as much on the list. If you're
interested in helping getting a full Tcl implementation that targets
Parrot up and running then drop him a line.</p>
<p><a href='http://groups.google.com/groups?selm=B74E9D35-7DF9-11D8-984D-000A95909DD0@coleda.com' target='_blank'>groups.google.com</a></p>
<a name='Ulterior Reference Counting for DoD'></a><h2>Ulterior Reference Counting for DoD</h2>
<p>Andre Pang pointed the list at a paper on yet another Garbage
Collection strategy called 'Ulterior Reference Counting' that looks
potentially interesting. However, it turns out that it doesn't quite
work that well with Parrot since Parrot guarantees that objects don't
move around.</p>
<p><a href='http://groups.google.com/groups?selm=3F38CC08-7E1F-11D8-AC03-000A95BAC4AE@algorithm.com.au' target='_blank'>groups.google.com</a></p>
<a name='Multi Method Dispatch vtable functions in bytecode'></a><h2>Multi Method Dispatch vtable functions in bytecode</h2>
<p>Dan announced that he'd started adding opcode support for multimethod
dispatch. Leo had a bunch of questions with no answers so far.</p>
<p><a href='http://groups.google.com/groups?selm=a06010203bc88de42bcc6@' target='_blank'>groups.google.com</a>[172.24.18.98]</p>
<a name='So that's where Jürgen's been'></a><h2>So that's where Jürgen's been</h2>
<p>After a long absence, Jürgen Bömmels appeared on the list and explained
that he'd got a new job, moved to a new town and had had no connection
to the Internet. He's currently working through a huge backlog of mail
and trying to get familiar with the current state of Parrot. It sounds
like it might be a while before he starts contributing patches to
ParrotIO again. Still, welcome back Jürgen.</p>
<p><a href='http://groups.google.com/groups?selm=m23c7vrh9p.fsf@helium.physik.uni-kl.de' target='_blank'>groups.google.com</a></p>
<a name='ParrotUnit'></a><h2>ParrotUnit</h2>
<p>Piers Cawley posted his initial version of ParrotUnit, a port of the
xUnit OO testing framework. Warnock applies.</p>
<p><a href='http://groups.google.com/groups?selm=m2vfksje9m.fsf@obelisk.bofh.org.uk' target='_blank'>groups.google.com</a></p>
<a name='Behaviour of PMCs on assignment'></a><h2>Behaviour of PMCs on assignment</h2>
<p>Dan noted that, right now, binary vtable functions take three
arguments, the destination, the left hand side and the right hand side,
which allows them to either take the type of the destination into
account, or simply to replace it with a new value. The advantage of
this approach is that vtable functions have the potential to be more
efficient when, say, the left hand side is the same as the
destination.  The disadvantage is that you have to make a PMC to
receive the results of the operation before you can actually do the
operation, which can be a pain (and suboptimal). Dan offered 3
different options and asked for opinions.</p>
<p>TOGoS argued that the 3 argument form was actually the Wrong Thing in
general and that vtable methods should simply create a new PMC and
replace the destination with it. He argued that this behaviour is what
most HLLs expect, and having it would make the compiler's life a great
deal easier.</p>
<p><a href='http://groups.google.com/groups?selm=a0601021cbc8a43044906@' target='_blank'>groups.google.com</a>[172.24.18.98]</p>
<a name='Meanwhile, in perl6-language'></a><h1>Meanwhile, in perl6-language</h1>
<p>They talked about Unicode a good deal, but (per my announcement a few
weeks back) I won't be covering those bits.</p>
<a name='Outer product considered useful'></a><h2>Outer product considered useful</h2>
<p>Luke Palmer proposed an <code>outer(*@ranges)</code> function to allow for what he
called 'dynamically nested loops'. He even provided an implementation
for it which used a coroutine. As Simon Cozens pointed out, the fact
that something as powerful as Luke's proposal can be implemented in
(initially buggy) pure Perl 6 with no need for any additions to the
language itself is very nice, but really more of a side issue for the
time being.</p>
<p><a href='http://groups.google.com/groups?selm=20040323000731.GA21533' target='_blank'>groups.google.com</a>%luke@luqui.org</p>
<a name='Announcements, Acknowledgements, Apologies'></a><h2>Announcements, Acknowledgements, Apologies</h2>
<p>No announcements (apart from &quot;Look! ParrotUnit! It's jolly good! You
should use it and send me patches!&quot;) this week. And if you think I'm
apologizing...</p>
<p>If you find these summaries useful or enjoyable, please consider
contributing to the Perl Foundation to help support the development of
Perl. You might also like to send me feedback at
mailto:<a href='mailto:p6summarizer@bofh.org.uk'>p6summarizer@bofh.org.uk</a>, or drop by my website, maybe I'll
<i>really</i> add some content to it this week.</p>
<p><a href='http://donate.perl-foundation.org/' target='_blank'>donate.perl-foundation.org</a> -- The Perl Foundation</p>
<p><a href='http://dev.perl.org/perl6/' target='_blank'>dev.perl.org</a> -- Perl 6 Development site</p>
<p><a href='http://www.bofh.org.uk/' target='_blank'>www.bofh.org.uk</a> -- My website, &quot;Just a Summary&quot;</p>
</div>
